サーキットブレーカーについて学んだのでざっくりまとめてみた

サーキットブレーカーについて学んだ内容をざっくりまとめてみました

#マイクロサービス

#AWS App Mesh

#AWS

なかた

2024.10.18

はじめに

こんにちは、アノテーションのなかたです。
今回は、サーキットブレーカーについて学んだ内容をざっくりまとめてみました。

サーキットブレーカーとは

サーキットブレーカーは、マイクロサービスアーキテクチャにおいて広く採用されているパターンの1つです。
2つのサービスの間に配置し、障害状況を監視しながらリクエストを制御します。
image (2)

また、サーキットブレーカーでは以下の３つのステータスが定められています。

Closed
Half-Open
Open

これら3つのステータスとそれぞれのステータスにおけるサーキットブレーカーの挙動について、以下に説明していきます。

`Closed`: リクエストがそのまま通る

Closed状態のサーキットブレーカーは、サービス間のエラーリクエストを監視します。
AサービスからBサービスへのリクエストで正常に処理されなかったリクエスト数をカウントします。

サーキットブレーカーを使用する際には、一般的にリクエストのエラー数に関するパラメータが事前に定義されます。
このパラメータを上回らない限り、ステータスはClosedであり続け、Bサービスへのリクエストは問題なく行われると判定されます。

`Open`: サーキットブレーカーによって、即座にエラーが返される

リクエストのエラー数が定義されたパラメータを上回った場合、ステータスはOpenとなります。
サーキットブレーカーの挙動として、Bサービスまで通信を介さず、Aサービスへ即座にエラーを返すようになります。
これによりリクエストがタイムアウトするまでの時間を短縮し、ユーザーの待機時間を短縮することで体験の向上が見込まれます。

`Half-Open`: `Closed`状態に遷移できるかどうか、少数のリクエストでチェックする

Open状態から一定の時間が経過した後、自動的にHalf-Openに遷移します。
少数のリクエストで通信ができるかどうかチェックを行い、できたらClosedへ、できなかったら再びOpenへ戻ります。
もしリクエストが成功すると判定されClosedに遷移する場合は、内部のリクエストのエラーカウント数をリセットします。

ステータスの遷移をまとめると

このような図になります。^[1]

AWSでサーキットブレーカー機能を導入する方法

AWS App Mesh

AWS App Mesh にてサーキットブレーカー機能が使用可能です。
詳しくは以下の記事をご覧ください。

また、AWSドキュメントではAWS Step Functionsを用いた実装方法についても記述されています。

ECSデプロイサーキットブレーカーは？

AWSでのサーキットブレーカーと考えて、最初に思いついたのがECSデプロイサーキットブレーカーでした。
そこで、マイクロサービスにおけるサーキットブレーカーとはどのように異なるのかを見ていきたいと思います。

ECSデプロイサーキットブレーカーとは、ECSでのタスクのデプロイにおいて働く機能です。間違ったタスク定義などをデプロイした際にデプロイエラーを検知し、自動でロールバックを行ってくれる機能になります。

そのためマイクロサービスのサーキットブレーカーと比べると同様の構造ではありますが、使われ方が異なると解釈しました。

まとめ

サーキットブレーカーを導入することで、エラーを迅速に返し、待機時間を短縮できる
サーキットブレーカーのステータスは、リクエストが通る状態を表しているわけではない

おわりに

図がわかりにくいので、わかりやすく描くスキルを磨きたいと思います。

参考

アノテーション株式会社について

アノテーション株式会社はクラスメソッドグループのオペレーション専門特化企業です。サポート・運用・開発保守・情シス・バックオフィスの専門チームが、最新 IT テクノロジー、高い技術力、蓄積されたノウハウをフル活用し、お客様の課題解決を行っています。当社は様々な職種でメンバーを募集しています。「オペレーション・エクセレンス」と「らしく働く、らしく生きる」を共に実現するカルチャー・しくみ・働き方にご興味がある方は、アノテーション株式会社採用サイトをぜひご覧ください。

脚注